i'm thinking about whether the Form object is the best home for this.

i know the older WorkForm serves in some ways as both a configuration object and as a data object/presenter. my experience has been that this has been something of a pain point (e.g. i think it's the main reason we haven't been able to make forms repopulate on failed submissions). i've been trying, only somewhat successfully, to limit our repetition of this pattern in ResourceForm. we still have primary/secondary terms, for instance, which are purely display configuration.

so i guess i'm open to this, but also wondering whether there's any downside to using a simple helper? <% form_tabs_for(form: f.object) %> with an implementation something like:

def form_tabs_for(form:)
  %w[metadata files relationships]
end

honestly, this could also be a viable pattern for moving away from #primary/secondary_terms?

(also, what's going on with tabs ||= here?! this should be a separate PR, but let's try just dropping that?)

ah. tabs is being passed in by the caller in some places. maybe a good idea to just have the caller pass it in always, but definitely out of scope.

on the other hand, this does mean we need to consider what other forms would need to implement this new method, and probably provide a fall back in case applications provide their own form objects.

I'm not entirely following. Are you suggesting using a helper or passing the tabs in or both?
My ultimate goal is having an engine plugin that can easily inject a new tab for the create/edit form without having to do any overrides and have this be on a per work-type basis. How would a plugin add a new tab if an application already has the helper implemented? With the form approach it seems straightforward with something like:

module Plugin
  module FormBehavior
    included do
      self.tabs += ['newtab']
    end
  end
end

Although there might be timing issues with that. I'm open to any approaches you think I should try.

sorry, i'll rephrase hopefully with more clarity.

what i understand to be happening now is:

• the guts4form partial accepts a tabs: [:blah] argument;
• if that argument is not passed in by render, we use %w[metadata files relationships] as the default;

the current state of this PR changes the second point to: use f.object.tabs as the default. that seems fine as far as it goes, but:

• i'm wondering whether putting this knowledge in the Form has advantages for applications over a helper which they could override.
  • i've been otherwise trying to keep the new ResourceForm objects as thin as backward compatibility allows, but i'm not strongly committed to that. i can say more about this if it's helpful.
  • i'm suggesting passing the form object into the helper so apps can choose implementations that switch tabs based on the form class, or other attributes of the form object (maybe this isn't needed?)
• i think the branching behavior in "happening now" above isn't great, and we should always have render pass in tabs: [:something], but that's probably out of scope for your goals and i don't want to foist it on you.